The detection of timeout conditions within data processes is typically performed to break deadlocks that may have occurred, and to avoid the dedication of resources of a data process to a particular data item to the exclusion of other data items. Timeout conditions are detected in a wide variety of data processing applications and devices. Such data processing applications may be implemented in software, hardware, or some combination thereof (i.e., firmware). Exemplary environments in which a deadlock (or stall) of a data process with respect to data item may be detrimental are instruction execution (i.e., software execution) and a networking (or interconnect) environment. For example, a deadlock during software execution may cause a computer system to “hang”. In summary, a deadlock or stall during processing of the network traffic may cause a severe degradation of network performance. Within both instruction execution and network traffic processing environments, there are a multitude of situations in which requests compete for specific resources.
Consider for example a new interconnect technology, called the InfiniBand™, that has been proposed for interconnecting processing nodes and I/O nodes to form a System Area Network (SAN). This architecture has been designed to be independent of a host Operating System (OS) and processor platform. The InfiniBand™ Architecture (IBA) is centered around a point-to-point, switched IP fabric whereby end node devices (e.g., inexpensive I/O devices such as a single chip SCSI or Ethernet adapter, or a complex computer system) may be interconnected utilizing a cascade of switch devices. The InfiniBand™ Architecture is defined in the InfiniBand™ Architecture Specification Volume 1, Release 1.0, released Oct. 24, 2000 by the InfiniBand Trade Association. The IBA supports a range of applications ranging from back plane interconnects of a single host, to complex system area networks, as illustrated in FIG. 1 (prior art). In a single host environment, each IBA switched fabric may serve as a private I/O interconnect for the host providing connectivity between a CPU and a number of I/O modules. When deployed to support a complex system area network, multiple IBA switch fabrics may be utilized to interconnect numerous hosts and various I/O units.
Within a switch fabric supporting a System Area Network, such as that shown in FIG. 1, there may be a number of devices having multiple input and output ports through which data (e.g., packets) is directed from a source to a destination. Such devices include, for example, switches, routers, repeaters and adapters (exemplary interconnect devices). Where data is processed through a device, it will be appreciated that multiple data transmission requests may compete for resources of the device. For example, where a switching device has multiple input ports and output ports coupled by a crossbar, packets received at multiple input ports of the switching device, and requiring direction to specific outputs ports of the switching device, compete for at least input, output and crossbar resources.
In order to facilitate multiple demands on device resources, an arbitration processing is typically employed to arbitrate between competing requests, associated with packets received at the input ports of the switching device, for device resources. An arbitration process to arbitrate between competing requests is an example of the process within which a stall or deadlock may severely degrade network performance. Accordingly, the IBA specification provides a number of timeout requirements (e.g., transmission and service timeout requirements).
Arbitration processes are typically either (1) distributed arbitration schemes, whereby the arbitration process is distributed among multiple nodes, associated with respective resources, through the device or (2) centralized arbitration schemes whereby arbitration requests for all resources is handled at a central arbiter. An arbitration scheme may further employ one of a number of arbitration policies, including a round robin policy, a first-come, first-serve policy, a shortest message first policy or a priority based policy, to name but a few.
As mentioned above, the IBA specification requires detection a number of timeout conditions (e.g., transmission timeouts and service timeouts). The detection of a number of timeout conditions within an arbitration process may also be desirable from a performance enhancement viewpoint. Nonetheless, the detection of timeout conditions does consume system resources, and it is desirable to minimize the impact of such timeout detection operations on overall system performance. For example, it is desirable to minimize the time dedicated to performing such timeout detection operations.